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A. 


Performance 


The primary purpose of this "Definition Phase" contract is 
to begin the preparation of a detailed Execution/Operations Plan 
that is consistent with the schedule of LAWS milestones and the 
updated data product definitions. This process has involved 
attending meetings, presenting papers, conducting preliminary 
studies and providing a draft of the Execution Phase Plan for the 
LAWS Science Team Leader. Our contract outlines several ongoing 
responsibilities to be met over the next 10-15 years of the EOS 
program. A review of those responsibilities and our related 
activities follows: 

1. Attend Team Member meetings 

This team member attended the August Science Team 
meeting in Boulder, CO and made the following presentations: 

- Report from the LAWS Simulation Committee 

- Optimal Scanning Patterns in Partly Cloudy Regions 

- Call for an Airborne LAWS Research Facility 

2. Support EOS Project with science related activities 

Given that LAWS has no space-based heritage, simulation 
studies are required to guide the system design, deployment and 
operation. The following activities have been partially funded 
by this contract: 

- co-organized (with R. Atlas, GSFC) a LAWS workshop on 
OSSEs and other simulation studies supporting LAWS 
design and data assimilation. The workshop was held 
27-28 March 1990 at GSFC. 

- conducted a series of LAWS performance trades involving 
scan angle, platform orbit and system baseline 
parameters (see 8 May 1990 Quarterly Report) . 

- modified the LAWS Simulation Model to create simulated 
data bases suited to assimulation by GSFC and FSU global 
circulation models (see 17 July 1990 and 1 November 1990 
Quarterly Reports) . 

- provided simulated LAWS observations to GSFC (Atlas) 
and FSU (Krishnamurti) and contributed to two papers 
for presentation at the Annual AMS meeting in New 
Orleans, LA (see 1 November 1990 Quarterly Report). 

3 . Prepare an Execution Phase Plan 

Drafts of updated team member study, management and 
cost plans were written and provided to the LAWS Team Leaders for 
planning and coordination of team member activities. In addition 
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to the team member plans, a general proposal for a LAWS Algorithm 
Development and Evaluation Laboratory was developed and submitted 
for Science Team approval. These documents were delivered to the 
LAWS Science Team Leader, Wayman Baker. Copies of the Team 
Member Plan and the LADEL Appendix to the Team Leader's proposal 
accompany this final report. 

4. Support LAWS and EOSDIS Related Work 

From time-to-time there are needs to interact with 
programs related to LAWS. These include GLOBE, EOSDIS, FIRE, 
GEWEX and ESA related activities. By necessity, team member 
involvement is limited by available resources and usually limited 
to attending meetings. Examples of these interactions, by this 
team member, on behalf of the LAWS Science Team follow: 

- EOSDIS Phase A review meeting, 12-16 February 1990, 

GSFC . 

- GLOBE meeting, 7-8 March 1990, Huntsville, AL. 

- EOSDIS Data Panel meeting, 21 March 1990, GSFC. 

- EOSDIS prototyping planning meeting, 9-11 May 1990. 

- ECMWF meeting to discuss future LAWS OSSEs, 3-5 
September 1990, Reading, U.K. 

- EOS IWG meeting at LaRC, 8 November 1990. 

These activities have exhausted the team member funds 
provided. In several instances, additional support has been 
found within other contracts. In other cases, labor and travel 
costs have been underwritten by the contractor. 



APPENDIX A 


LAWS ALGORITHM DEVELOPMENT AND EVALUATION LABORATORY 

(LADEL) 


Wayman Baker 
Team Leader 

1.0 Introduction 

Each Facility Team is required to deliver 3 sequential 
versions of science data processing software to the Ground System 
and Operations Project (GS&O) prior to the launch of the Facility 
instrument ( s ) and to maintain and update that software for a 
period of 15 years. The LAWS Facility Team is required to 
establish a Science Data Processing Software Team that will be 
responsible for the design, coding, testing, delivery, 
documentation and maintenance of such software. While science 
algorithms will be developed by individual Team Members (TMs) for 
their own research, the team as a whole is required to deliver to 
the EOSDIS project operational code to produce standard data 
products for use by the broader community of researchers. 

The LAWS Team Leader (TL) has the ultimate responsibility 
for the LAWS data processing software. Given that LAWS will be 
the first space-based laser wind sounder ever launched, much of 
the algorithm development and evaluation will be conducted in a 
simulated environment. NASA has already developed a simulation 
capability that is currently being used to evaluate LAWS 
configurations, orbit selection and impacts on global climate 
diagnostics and numerical weather forecasts. 



It is proposed that the data processing software be the 
final responsibility of the Team Leader through the 
implementation of a facility to be referred to as LADEL (LAWS 
Algorithm Development and Evaluation Laboratory, Fig. 1) . LADEL 
will not only serve EOSDIS directly but will also serve the TMs 
in their individual research projects. LADEL would serve as a 
single point of contact for the GS&O project. The overall 
performance of LADEL would be controlled by the TL and the LAWS 
Science Data Processing Software Team. 

LADEL is composed of two primary segments (Fig. 2) which 
represent its responsibilities to the design and evaluation of 
optimum LAWS configurations and sampling as well as to the 
delivery of fully functioning and tested algorithms to EOSDIS for 
the production of standard data products. Segment 1 includes all 
team functions related to the design, coding, listing and 
documentation of LAWS EOSDIS Science Data Processing Software 
(SDPS) . Segment 2 provides support to the science team members, 
the EOS project (GSFC) and LAWS Instrument Facility project 
(MSFC) in developing optimal LAWS configurations, sampling 
strategies and algorithms. A more detailed description of these 
two segments is provided in Section 4.0. 

2.0 Rationale 

The EOS project is committed to a Data Information System 
(DIS) that will provide the science community with processed 
science data products on a near-real time schedule immediately 
after launch of EOS A. Enchanced access to both EOS and non-EOS 



data is a primary goal of the EOSDIS design. While wanting to 
assure sufficient common abilities to achieve functionality , the 
EOSDIS project also recognizes the need to remain flexible and to 
accommodate the varied types of data formats and analysis 
requirements that are represented by a broad spectrum of EOS 
investigators . 

To achieve an acceptable level of functionality the EOS 
project has established policies and guidelines to promote a 
common approach to software development by the more than 500 EOS 
investigators in order to develop portable code and provide 
similar documentation for all of the Science Data Processing 
Software. They are also intended to contribute to a higher level 
of overall software quality, to assure that the software can be 
easily integrated into the EOS Data and Information System 
(EOSDIS) , and to assure that the software can be maintained for 
the life of EOS. 

Policies are requirements levied by the EOS Ground System 
and Operations (GS&O) Project on the Science Data Processing 
Software development process. It is recognized that policies can 
not be applied blindly and that unique situations will exist that 
warrant a deviation from or waiver of the policy. 

Guidelines are recommendations and suggestinons that have 
proven to be beneficial on software development projects in the 
past . 

Development of standard products, and special products with 
the potential to become a standard product, are subject to these 
standards and guidelines. The Facility Instrument (FI) 


investigation teams that develop the Science Data Processing 
Software are referred to as "software teams". 

Software for producing a specific data product from an 
instrument's measurements will be developed by individual team 
members (TMs) and co-investigators (Co-Is) . This software will 
be integrated on an instrument and discipine basis by the 
responsible team leader (TL) . It is the responsibility of the 
TLs to develop approaches and schedules that will assure the 
software meets quality standards and GS&O schedules. 

Science Data Processing Software is developed by many of the 
more than 500 EOS investigators. The software from this diverse 
and widely distributed population must be integrated and must 
work together in a standard data production environment. In 
addition, the software must be maintained for the planned 
lifetime of the EOS mission of more than 15 years. 

The intent of these policies and guidelines is to assure 
that Science Data Processing Software is developed in a 
consistent manner so it can be smoothly integrated, operated, and 
maintained. Software is required to be readable, portable, and 
reliable. The standard therefore specifies a flexible 
development methodology with (minimal) required documentation and 
periodic reviews to provide project-level visibility into the 
software development activity. It also specifies the use of 
relevant public standards to assure that the software is 
portable . 

Adhering to these policies and guidelines benefits the EOS 


program in many ways : 


• Facilitates the Peer Review process for algorithms and 
code ; 

• Facilitates algorithm and code sharing among scientists; 

• Facilitates the integration of the Science Data Processing 
Software into the EOSDIS environment; 

• Facilitates transitions in Science Data Processing 

Software maintenance responsibilities in later years when 
the original developers may no longer be available; 

• Helps data users understand the processes by which 
science data are derived; 

• Helps EOSDIS operations staff quickly determine whether 
Science Data Processing Software or support software is 
responsible for production problems; 

• Facilitates algorithm software changes over time as 

science requirements change during the course of 
research; and 

• Facilitates any software conversions required when EOSDIS 
computers are replaced. 

3.0 LAWS Team Responsibilities 

3 . 1 Investigation and Data Product Definition 

The science mission of the EOS will be conductd by three 
types of investigator teams: 

• Facility instrument teams such as LAWS conduct 

investigations that use one of the facility instruments 
being developed by the EOS Project. Each facility 
instrument team consists of a TL, TMs, and Co-Is. 

• Instrument teams develop and conduct investigations 



on their own instruments. Each such instrument is 
the responsibility of a PI supported by a number of 
CO-Is . 

• Interdisciplinary teams conduct investigations based 
on products and data from multiple EOS instruments and 
other sources. Each interdisciplinary team consists 
of a single PI and a number of CO-Is. 

Data products will be generated by the Data Products 
Software within and outside the EOSDIS production environment. 
These data products are characterized as standard or special 
products, metadata, and browse data. 

Standard products are identified as normal project 
deliverables and are produced at a DAAC for spatially and/or 
temporally extensive sets of data. Special products are science 
data products considered part of a specific research 
investigation and produced at a Science Computing Facility (SCF) 
for a limited region or time period, or data products not 
accepted by the project as standard items. 

. Metadata is descriptive information about a standard or 
special product. It defines characteristics of the data, and 
includes other information such as a description of the process 
used to create the data product, how the product was validated, 
etc. A browse data set is a reduced-volume version of a standard 
or special product that maintains the statistical properties of 
the original. 


3 . 2 Overview of the Software Development Process 

Each investigation team is responsible for developing the 


software that generates the data products associated with their 
investigations. To this end, each investigation team shall have 
an associated FI software team. 

3 . 3 Parallel Software Development 

Science Data Processing Software developed by an individual 
investigator is ultimately integrated into a production 
environment with Science Data Processing Software developed by 
other investigators. This integrated production environment has 
to generate all of the data products required to support the EOS 
scientific investigations. 

Science Data Processing Software comprise two distinct 
segments. The first segment, the "science algorithm", is the set 
of routines responsible for performing the mathematical 
manipulations of the input data to produce the desired output. 

The second segment, referred to hereafter as the "shell", is the 
set of routines that controls execution of the science algorithm 
and provides the interaction with the EOSDIS processing 
environment (e.g., Input/Output and operator interface) . The 
shell is the infrastructure of the Science Data Processing 
Software, i.e., everything except the actual science algorithm 
code . 

The development of these two segments is done in parallel. 
The shell is defined by EOSDIS interface requirements and system 
design. It also derives its requirements from the interface 
requirements of the science algorithms. Both segments are 
designed and implemented to complement each other and EOSDIS to 
meet the data production performance requirements. 


Development of the shell segment follows the development 
methodology described in the next section. The science algorithm 
code may be developed according to the individual investigators 
methodology. However, science algorithm code must satisfy 
quality standards and the delivery schedules for version 1 
through 3 . 

3 . 4 Integration and Test Phase 

Upon completion of software unit testing, the units are 
integrated together and then integrated into the target system. 
Integration of Science Data Processing Software will be conducted 
in three steps: TM local integration and test, TL software 

system integration and test, and EOSDIS DAAC central integration 
and test. 

3.4.1 TM Local Integration and Test 

-As shell and science algorithm code become available from 
the implementation effort, they are integrated and tested to 
verify compatibility and to achieve functional interaction 
forming the subsystem. The subsystem is integrated locally to 
verify that it satisfies the requirements allocated to it. 

To facilitate the integration of the software, the 
developers produce test data characteristic of the instrument 
data stream. EOSDIS provides, at the developer's request, 
simulated platform ancillary data that can be merged with the 
instrument test data set. 

3.4.2 TL Software System Integration and Test 

Upon completion of the subsystem integration and test, each 
TM delivers the shell and science algorithm code to the 



responsible TL. The TL integrates the subsystems to form one or 
more Science Data Processing Software programs. The TL tests the 
programs using the test data sets provided by the TMs . The 
integration and test occurs at the TL's home institution or at 
the TL/PI ' s designated test site. 

3.4.3 EOSDIS DAAC Central Integration and Test 

Upon completion of testing at the TL's home institution or 
designated test site, the team's Science Data Processing Software 
"system" is ported to the associated DAAC within EOSDIS. The 
software teams repeat their development tests to assure that 
their software operates within the EOSDIS environment. 

3 . 5 Sustaining Engineering and Operations 

In the Sustaining Engineering and Operations Phase the 
operational capabilities of the software are sustained, and 
repairs and upgrades are made within the context of the original 
concept of the software. In the event that the hardware must be 
upgraded or modified, testing of the software must be performed 
to revalidate the integrated software. Sustaining engineering 
activities are conducted by the software developers. 

3 . 6 Software Management 

Each EOS FI team shall have a designated person responsible 
for the Science Data Processing Software development efforts. 

This person is referred to as the Data Processing Software 
Manager (DPSM) . 

The DPSM shall be responsible for software planning and 
sizing, resource estimation, monitoring and control, reporting, 
product assurance, configuration management, software product 


deliveries, and for presentations to the GS&O Configuration 
Control Board (CCB) for software product acceptance and 
baselining . 

Each DSPM shall coordinate all communications concerning the 
Science Data Processing Software development efforts through the 
responsible GS&O Software Manager. 

Each FI software team shall prepare, maintain, and adhere to 
a Software Management Plan (SMP) . 

The SMP shall address the following topics, at a minimum: 

■ Engineering and integration planning (including planned 
development methodology and development adaptations) ; 

• Documentation to be produced during each phase; 

■ Required resources, budgets, and schedules; 

• Risk Management planning (identification of development 
problems) ; 

• Configuration Management planning; 

• Quality Assurance planning; 

• Software sizing estimates; and 

• Approved deviations and waivers. 

The DPSM shall submit to the responsible GS&O Software 
Manager via electronic mail a monthly status report. The monthly 
status report shall present, at a minimum: 

• Significant accomplishments since last report, 

• Deliverable items status, 

• Schedule performance and status, 

• Cost performance and status, 

• Product performance, 



• Summary of results from internal reviews, if any, 

• List of problems with description of causes, overall 
effect, and recommendations for corrective action, 

• List of issues and concerns, 

• Summary of open action items, 

• Disposition of action items closed during the reporting 
period, 

• Latest estimates of software size, CPU usage, and end-to- 
end processing time on a specified computer, 

• List of planned internal or formal reviews, 

• List of actions requested of GSFC management. 

Each FI software team shall develop and deliver the followig 
minimum set of documentation during (or at the conclusion of) the 

specified phase: 

Document Phase 

Software Management Plan Concept Definition 

Data Users Guide Implementation (each delivery) 

System Description Document Implementation (each delivery) 
Algorithm Description Document Implementation (each delivery) 
Operator ' s Guide Implementation (each delivery) 

Version Description Implementation (each delivery) 

Regular peer reviews should be utilized to improve the 
quality and accuracy of the requirements, design, code and 
testing performed during the development. 

The DPSM shall establish a mechanism for peer review and 


certification. 


4 . 0 Description of LADEL 

As mentioned earlier, LADEL is a LAWS Team facility 
established by the team leader to support and enhance the 
development of an optimal LAWS and its related algorithms and to 
meet the EOS requirements for delivered standard data product 
software. LADEL is to be the focal point for integrating the 
contribution of individual team members, the EOS project (GSFC) 
and the LAWS project (MSFC) into the process of developing, 
testing, and evaluation of "operational" software that is to be 
executed in the EOSDIS environment (s) . In its relationship to 
the interests and responsibilities of individual team members, 
LADEL is designed to: 

• provide simulated data sets to TMs, 

• communicate EOSDIS software requirements as they 
relate to LAWS, 

• provide access to global simulation test beds for 

evaluating TM science algorithms, 

• convert TM "science or research code" into EOSDIS 
operational code, 

• accept responsibility for the EOS required software 
management, reviews, documentation, etc. 

4 . 1 Components 

LADEL is a computer facility staffed with personnel trained 
in data/ software management, computer systems engineering, 
numerical modeling, and meteorological data analyses. Initially 
LADEL will be built around three current capabilities: 



1) Global OSSE simulation software 

2) Regional/Engineering simulation software 

3) EOSDIS prototyping heritage. 

4.1.1 Global OSSEs 

4.1.2 RLSM 

4.1.3 EOSDIS Prototyping at University of Virginia 

4 . 2 Management Plan 

LADEL provides the LAWS Science Team with an end— to— end data 
system test capability to satisfy EOS project requirements. 

LADEL and its management is the direct responsibility of the TL. 

The TL proposes to delegate the day-to-day management of 
LADEL to team member already involved with LAWS simulations and 
EOSDIS design and prototyping. The management structure is shown 
in Fig. 3. 

[EXPAND] 

4 . 3 Facility Requirements 

In general, LADEL will share many of the hardware/software 
and human resources that will already be in place for the 
designated team members SCF . The budget in Section 5, however, 
assumes no overlap. The degree of overlap is discussed in 
Section 5.3.2. In this section, facility requirements are 
listed . 

4.3.1 Computational Requirements 

A minimum of 3 workstations on a LAN will be required. The 
necessary computational capacity is TBD. The system must be able 
to handle those components of EOSDIS that are needed to develop 

Level 1 to Level 4 algorithms will have to be 


and test SDPS . 



executable on this system as well. 

[ EXPAND ] 

4.3.2 Communications 

It is assumed that all communication links will be provided 
as GFE. 

4.3.3 Personnel 

At a minimum the following personnel will be required to 
staff LADEL: 

- Manager 

(responsibilities) 

- 3 staff programmers 

- secretary 

- numerical modeler 

- science data analyst 

4.3.4 Travel. Training, Meetings, Reviews 

Given the interactive nature of LADEL with the LAWS Science 
Team, the LAWS Instrument Facility (MSFC) and the EOSDIS project 
(GSFC) , there will be considerable travel and other costs 
associated with meetings, reviews, and training. 

5.0 Budget 


See attached table. 



Figure 1 
L A D E L 

LAWS ALGORITHM DEVELOPMENT AND 
EVALUATION LABORATORY 


PURPOSE 

■ Provide an end-to-end data system test capability for the 
development and evaluation of LAWS team member algorithms 
for Level la-Level 4 products. 

• Provide the capability and the support personnel 
for insuring EOSDIS functionality of the 
algorithms prior to integration. 

• Provide a laboratory for performing hardware trade studies 
including instrument configuration, shot management, etc. 

• Provide a set of models and simulation software for 
developing interpretive skills through OSSE's and general 
circulation simulations. 

• Generate simulated LAWS data sets (Levels 0-4) for pre-launch 
testing for EOSDIS - platform to data archives to science 


work stations. 



Figure 2 

LAWS ALGORITHM DEVELOPMENT AND 
EVALUATION LABORATORY 
(LADEL) 


SEGMENT 1 

EOSDIS Science Data 
Processing Software 

• LAWS Standard Products 

• EOSDIS Requirements 

• Software Management 

• Data User's Guide 

• Operator's Guides 

■ Software Acceptance Tests 

• Code Optimization 

• Support of Special Product 

Development 


SEGMENT 2 

Simulations and Science 
Algorithm Evaluation 

• Global OSSEs 

« Regional OSSEs 

• Data Product Defini- 

tion 

• LAWS Performance 

Evaluation 

• Pre-launch Sampling 

Management Simula- 
tion 

. Post-launch Sampling 
Reprogramming 

• Simulated Level 1 - 

4 products 

• GLOBE Data Incorpora- 

tion 


Figure 3 
LAD EL 


Management Structure 
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PREFACE 


1. Abstract 

The proposed Lidar Atmospheric Wind Sounder (LAWS) will 
provide the geophysical research and operations communities with 
the first space— based set of directly measured clear— line— of — 
sight winds on a global scale. These LAWS winds combined with 
other EOS instrument measurements of moisture and temperature 
will allow the advection and divergence of moisture, mass and 
momentum to be computed over regions of the globe currently 
unobserved with regards to tropospheric . winds . The impacts of 
such an observation on basic understanding of the biosphere and 
the subsequent forecasting of global atmospheric and oceanic 
phenomena will undoubtedly be greater than any impact that can be 
assessed through simulations today. 

LAWS will measure the winds in a manner that is unique among 
all current wind sensing technologies. Although similar to 
Doppler radar in its principles of wind detection, the lidar' s 
sample frequency, volumes and spatial distribution require unique 
approaches to sampling strategies and wind computation 
algorithms. This team member proposal addresses both of the 
sampling and wind computation issues and outlines a work plan 
that builds upon current efforts by the PI to develop algorithms 
that could be used to generate Level 1 and Level 2 data sets for 
EOS. 


Atmospheric aerosols, very thin cirrus, and cloud tops will 
provide the backscatter for Doppler lidar wind measurements. The 
global distribution of backscatter is currently assessed by the 
GLOBE so that the facility team will have a rational basis for 
instrument design specifications. This proposer has participated 
in the backscatter survey studies and will use the results in 
simulating LAWS performance as well as in conducting additional 
studies to demonstrate the synergisms between several remote wind 
sensing techniques — e.g., cloud tracked, water vapor tracked 
and scatterometer (STICKSCAT) winds and temperature sounders 
(AIRS) . 

During the pre-launch period, emphasis will be placed upon 
the following issues which are critical to the final 
conf igurat ion/operat ion modes for LAWS and to the algorithm for 
producing Level 1 and 2 data products: 

1) shot management objectives and shot control 
requirements ; 

line-of-sight local context processing for a Level 
1 product (includes data extraction in the PBL, 
cloud tops and in partly cloudy scenes) ; 


2) 



3) model . independent Level 2, horizontal wind vector 
product . 

After LAWS is launched, the sampling and wind computation 
(Level 2B) algorithms will be evaluated using ground-based wind 
measuring facilities as well as numerical models. LAWS data will 
be combined with other remote wind sensing data sets in addition 
to data from ground-based networks to study the relationship of 
upper tropospheric divergence/vorticity fields with storm 
dynamics and precipitation. 


II. INVESTIGATION AND TECHNICAL PLAN 

1.0 Introduction 

In Section II the proposed objectives are spelled out and 
the background for the proposed contribution to the LAWS facility 
team is presented along with the technical plan' for achieving the 
objectives. Most of the planning detail is focused upon the 
Definition Phase since, in the case of LAWS, the evaluation 
strategies and data application will depend upon how the 
instrument concept matures over the next few years. 

The application of LAWS data to relating the upper 
tropospheric divergence near convective storms to other storm 
attributes will occur in the post-launch phase of the 
Execution/Operations (E/0) Phase. Pre-launch efforts will be 
directed mainly towards selecting the appropriate models to be 
used in that study and using limited data sets collected with 
ground-based and perhaps airborne Doppler lidar systems. 

2.0 Execution Phase Objectives 

2.1 Pre-launch Objectives 

As a member of the LAWS Facility Team the PI proposes to 
coordinate and participate in instrument design/application 
activities associated with: 

a) development of adaptive and non-adaptive space- 
based lidar sampling strategies to optimize the 
operation of a "shot-limited lifetime" facility; 

b) development and evaluation of horizontal wind 
computation algorithms for Level 2 ungridded data 
products ; 

c) definition of potential formats for the general 
archiving of Levels 1, 2 and 3 LAWS data in the 
EOS Data and Information System (EOSDIS) ; 

d) development of a Cloud/Aerosol Wind System (CLAWS) 
that will capitalize on the synergistic relationships 



between cloud (and water vapor) tracked winds and 
LAWS ; and 

e) investigation of the combining of scatterometer (SCATT) 
derived winds over the oceans with the more directly 
measured LAWS winds [work with R. Brown] . 

2.2 Post-launch Instrument and Science Objectives 

After the launch of LAWS, the primary objectives will be: 

a) evaluation of the LAWS wind computation algorithms by 
use of ground-based calibration facilities and numerical 
models ; 

b) providing user data to the EOSDIS and meeting the 
obligations of facility team members as outlined in 
Part 1 of the EOS BIP; 

c) use of the LAWS and other remotely sensed wind data 
(cloud tracked and scatterometer) to study the observ- 
able relationships between lower tropospheric conver- 
gence, rainfall, and upper tropospheric divergence in 
the presence of meso-6 and larger scale convective 
storm systems — in paticular tropical cyclones [work 
with J. Molinaro and T. Miller]. 

3 . 1 Background 

Unlike other designated NASA research facility instruments 
such as MODIS , HIRIS and SAR, LAWS has no heritage of space-based 
operations. Never before has a laser been flown in space to 
measure aerosol backscatter and the clear-line-of-sight (CLOS) 
component of the winds. Expectations of success are based upon 
ground-based (DiMarzio et al., 1979; Post et al., 1978; Emmitt, 
1984; Rothermel et al., 1985) and airborne (Bilbro et al., 1984, 
1986; Emmitt, 1985; Schweissow et al., 1976; Vaughan and 
Woodfield, 1983) demonstrations of lidar wind detection 
capabilities as well as computer simulations (Arnold et al., 

1985; Atlas et al., 1985; Emmitt and Houston, 1986; Huffaker, 
1978; Menzies, 1986) of the likely performance of a space-based 
system (Fig. 1) . There is, therefore, a particularly strong 
charge to the LAWS facility team to evaluate, in depth, all 
aspects of a space-based wind sensor prior to the final design 
and construction of the instrument. 

LAWS, like its predecessor concept WINDSAT, has been 
generally driven by the meteorological community's desire to get 
wind profiles over the entire globe at "radiosonde" resolutions 
(i.e., *• 300 km spacing) . While synoptic scale flow features are 
targeted for resolution, phenomena with length scales less than a 
few hundred kilometers will not only influence the wind 
computation for the larger scales but may also be resolvable with 
proper algorithms for combining clear-line-of-sight (CLOS) 



components to compute horizontal winds (Emroitt, 1984, 1985, 1986, 

1987, 1988). Much of the following proposed effort builds on 

this earlier and current work on LAWS simulations and algorithm 
development. 

It is not appropriate for this proposal to go into any 
detail on the principles of lidar operation. Much of that detail 
is contained in the LAWS Instrument Panel Report to which the 
proposer made several contributions. However, several 
considerations of the LAWS concept need to be reviewed to provide 
background for the proposed facility team effort. These 
considerations are stated as follows: 

• LAWS will obtain direct measurements of the line-of-sight 
(LOS) component of the mean size-weighted motion vector 
of the aerosols within the sample volume (length => 500 m; 
diameter ■ 10 m) . 

• Correct height assignment of the LOS component depends 
upon the homogeneity of the concentrations and size 
distributions of the distributed targets incorrect 
height assignment can lead to considerable wind velocity 
computation errors when LOS measurements are combined _ 
to compute a horizontal wind vector (e.g., in the marine 
boundary layer or near convoluted Planetary Boundary 
Layer (PBL) inversions) . 

• While the accuracy of the LOS measurement may be 
primarily a function of the Signal-to-Noise Ratio (SNR) 
in the backscattered information, the representativeness 
(or lack thereof) of each LOS provides a source of "error" 
in the horizontal wind computation — the magnitude of 
this error is directly related to the spatial distribution 
of the lidar shots. 

• The lifetime of a pulsed C0 2 lidar is a major issue in the 
LAWS program. Lifetime is expressed in terms of numbers 
(=» io -1CT) of pulses or shots. Shot management can both 
minimize sampling errors as well as extend the service 
lifetime of a LAWS instrument. 

• Overall impact of LAWS on science will depend directly 
upon the availability of aerosols and CLOSs. Thus cloud 
and aerosol climatologies are needed for LAWS pre-launch 
performance studies. 

Several of the considerations listed above have already been 
given preliminary attention by the proposer through a series of 
NASA funded studies regarding the influence of mesoscale coherent 
features on the computation of LAWS wind profiles. These studies 
have produced two preliminary versions of a Shot Management 
Algorithm (SMA) and a Multi-Pair Algorithm (MPA) . 



3.1.1 Shot Management Algorithm (SMA) 

The development of the SMA was begun to optimize the 
distribution of shots to 1) achieve better wind estimates and 2) 
to extend laser lifetimes (Emmitt, 1985). Initial versions of 
the SMA optimize lidar shot distributions by choosing optimum 
combinations of lidar scan rate and pulse repetition frequency. 

It is proposed to improve on this first order optimization by 
looking at asynchronous pulse control. 

The second task of the SMA is to suppress shots in regions 
of the globe where the information potential is low (e.g., over 
the poles every 90 minutes) and obtain higher than normal shot 
density in areas of greater interest (e.g., tropical cyclone). 
Preliminary computations suggest that, using the criteria of 
constant temporal/spatial wind information density, an extension 
of laser lifetime by a factor of 1. 5-2.0 could be realized. 
Further evaluation of this level of shot management will be 
conducted during the Execution Phase. 

3.1.2 Multi-Pair Algorithm 

In early feasibility studies performed by NOAA (Huffaker et 
al., 1978), all the forward and aft shots into 300 km x 300 km x 
1 km volumes were combined using a least squares approach which 
assumed that variations in the LOS measurements within that 
volume were spatially independent and that the vertical velocity 
could be assumed to be zero or very small compared to the 
horizontal wind components. In areas with significant wind 
structure both in the vertical and horizontal planes these 
assumptions do not hold. Emmitt (1985) proposed a more general 
approach that presumed no a priori averaging volume and would 
work better than the least squares approach in regions of 
coherent wind features having length scales 3 100 km. This 
approach is referred to as the Multi-Pair Algorithm (MPA) . More 
detail on the MPA and its comparison with the LS approach are in 
NASA progress reports (Emmitt, 1985, 1986, 1987) . 

The application of the MPA to a global wind data set is 
illustrated in Figs. 3, 4 and 5. The regions of largest errors 
(Fig. 5) are along the outer edge of the scan domain as well as 
in the area of the subsatellite ground track. However, most of 
the scan domain exhibits small speed errors with some spatially 
coherent biases in the cross and along track component errors. 

Although the MPA has reduced the wind measurement errors, 
there remain several areas that need investigation and perhaps 
improvement. First, since the spatial separations between 
members of a shot pair may be commensurate with spatial variation 
in backscatter structures, there could be another source of error 
unaccounted for in the current wind computation algorithm 



evaluation. Second, the value of using the LOS measurements 
without pairing should be considered. That is, the LOS data 
could be used to regress against a model wind field based upon 
other inputs such as ground-based observation, cloud tracked 
winds, computed geostrophic winds, etc. In fact, the LOS data in 
the error prone regions of the lidar scan domain could be used to 
regress against wind vectors interpolated from the areas with 
good MPA horizontal wind estimates. 

3.1.3 LAWS System Models and OSSEs 

The SMA and MPA described above are currently being used in 
SWA's LAWS System Model (LSM) and in Observing System Simulation 
Experiments (OSSEs) conducted at GSFC. The purpose of the OSSE's 
is to assess the impact that LAWS might have on global scale 
forecasts. Earlier OSSEs (Atlas et al., 1985), which did not 
consider the cloud limited sampling of LAWS nor the wind speed 
estimate biases, showed substantial improvement in forecast skill 
on the average for the southern hemisphere and occasionally in 
the northern hemisphere. OSSE's currently being conducted 
include both the cloud and speed bias features of LAWS profiles. 
Emmitt and Wood (1988) have recently begun looking at how to 
include the contributions of subvisible cirrus to the LAWS 
detectable wind fields. The PI will continue to work closely 
with both the LAWS facility team as well as researchers in the 
International Satellie Cloud Climatology Programs (ISCCP) to 
document the global coverage of thin cirrus. 

3.1.4 Storm-top Circulations 

Much of what we know about the circulations associated with 
significant storms is based upon surface networks of anemometers, 
aircraft mounted probes, Doppler radars and special rawinsonde 
releases. The surface networks provide us with quantifiable 
evidence of downwind vertical mass transports. The strengths of 
these surface flows have been related to convective storm 
attributes such as precipitation (Ulanski and Garstang, 1978; 
Watson and Blanchard, 1984). 

Aircraft have given us detailed information on the 
turbulence and vertical velocity features inside and outside of 
storms. The aircraft mesurements have provided links between 
surface measurements below the clouds and Doppler radar wind, 
measurements within clouds and the winds external to clouds in 
the middle troposphere where no other observational techniques 
(except for recently developed microwave sounders) work. 

EOS instruments will provide an on-top perspective of 
storms. Considerable advances have been made in relating storm- 
top radiative properties to the dynamics and precipitation of the 
convective system (Barrett and Martin, 1981; Wilheit et al., 

1982; Adler, 1988; Spencer et al., 1983).. Another approach to 
infering storm-dynamic/precipitation physics is to use satellite 
observed anvil growth rates (need ref.). LAWS will provide an 



additional measure of storm-top dynamics with the direct 
measurement of winds. With present LAWS design criteria the 
minimum spacing between wind observations will be * 50 km. This 
resolution will limit the study to meso-6 systems unless the 
instrument is modified to permit a higher resolution mode of 
sampling. It is proposed that in the post-launch phase the LAWS 
data will be combined with other remotely sensed data for several 
case studies to look for useful relationships between the upper- 
tropospheric divergence and vorticity fields and other convective 
storm parameters (e.g., vertical velocities, mass transport, 
water conversion rates, etc.). 

4.0 Technical Plan 

In achieving the stated objectives, frequent interactions 
and cooperative activities with other facility team members are 
anticipated. Close coordination between the hardware engineering 
studies and the data acquisition and processing algorithm 
development will be critical to the evolution of an optimum final 
LAWS design. The following outline of the proposed technical 
plan takes such interaction as a given and does not deal in 
detail with any anticipated parallel studies. 

4.1 General Design 

The proposed work for the execution phase is partitioned 
into two phases: 

1) Execution/Operational Phase — Pre-launch. During this 
period, the Level 1 and Level 2 data algorithms will be 
finalized and implemented in the EOSDIS; scanner/pulse 
design and control algorithms will be firmed; and back- 
scatter data will be used in detailed simulation studies 
to assess potential impacts on instrument design as well 
as geophysical research. 

2) Execution/Operations Phase — Post-launch. LAWS 
performance will be evaluated using ground-based wind 
measuring facilities and the numerical models used 
during the pre-launch simulations. LAWS data will also 
be used to conduct the proposed scientific research 
which, involves the incorporation of several wind sensing 
systems . 

Below, each objective listed in Section 2.1 is expanded and 
a plan for reaching that objective is presented. 

4.2 Optimum Sampling Patterns 

The current LAWS design calls for a fixed scale angle (value 
TBD) , fixed scan rate (value TBD) and asynchronous triggering of 
the laser pulse. With this configuration, shot management is 
limited to the scheduling of the pulses. 



The selection of shot management strategies for evaluation 
will be based upon discussions within the facility team and with 
other EOS teams involved with scanning instruments. 

The selected management options will be programmed into 
existing SWA LAWS simulation models. The models will then be run 
on control wind data to produce: 

a) shot distribution maps 

b) velocity vector maps 

c) error vector maps 

d) an overall performance index (global coverage) . 

Sampling pattern evaluation will be carried into the pre- 
launch portion of the E/0 Phase for further evaluation in OSSE's 
and refinement. 

4 . 3 Shot Management 

During the Definition Phase, the facility team has been 
provided with detailed information regarding the potential 
advantages of shot suppression and "bursting" — i.e., providing 
higher than average shot density in regions of special interest. 
The primary advantages to shot management are increased lidar 
lifetime and increased information where it is needed. The 
primary disadvantage, initial cost, may be offset by the incresed 
"time-in-service" . 


Several shot management options will be identified and 
preliminary evaluation performed during the Execution Phase using 
currently available LAWS simulation models. This work will be 
done in parallel with the optimum pattern and completed in the 
same time frame. 

In the pre-launch phase, the selected shot management option 
will be further evaluated and operational software developed. 

4.4. Wind Computation Algorithm 

Most of the Execution Phase effort will focus upon 
operational shot management strategies. However, since the 
accuracy of the LAWS wind measurements will be a major 
consideration in that selection, a means of computing the 
horizontal wind from the LOS components must be defined for use 
in the simulations. It is proposed that several algorithms be 
selected and used during the Execution Phase with more advanced 
development scheduled for the post-launch portion of the E/0 
Phase. The selection of standard wind computation algorithms for 
the Execution Phase will be made by the facility team. 

Refinement of the current MPA or development of new wind 
computation algorithms will be done during the pre-launch portion 
of the E/0 Phase. Technical papers and conference presentations 
will result from this effort. 



4.5 Definition of Level 1, 2, and 3 Data for EOSDIS 

It is expected that the details of those products will 
undergo revisions as the instrument concept matures. The current 
product definitions are summarized in a document entitled "LAWS 
Data System Preliminary Requirements". 

4.6 Development of CLAWS 

The development of a hybrid cloud/aerosol wind system 
(CLAWS) consists of cloud tracked winds from GOES E/W and LAWS is 
scheduled for the pre-launch period of the E/0 Phase. The 
application of CLAWS to the science objectives of studying the 
storm-top circulation will be a post-launch task. 

Cloud imagery from GOES E/W archives wjlll be processed on 
the McIDAS system at MSFC by SWA personnel or on a PC-McIDAS 
located in Charlottesville, VA. Cloud tracked winds will be 
obtained using standard techniques. These winds would then be 
combined with simulated LAWS winds using the LAWS Simulation 
Model (LSM) in residence at MSFC and/or at SWA. 

Critical issues to be addressed will be: 

1) height assignment of cloud track winds using LAWS 
based information; 

2) reconciliation of differences at boundaries of cloud 
track wind zones and aerosol wind (LAWS) zones; and 

3) availability of semi-transparent cirrus for middle 
to upper tropospheric wind data. 

4.7 Scatterometer and LAWS Winds 

A scatterometer (STICKSCAT) similar to the one on SEASAT is 
scheduled to fly as part of EOS. The scatterometer provides a 
measure of the winds near the ocean surface by inferring wind 
stress from the backscatter off the capillary waves on the wave 
surface. LAWS may not obtain reliable wind speed data in the 
lowest few 10' s of meters near the ocean surface because of 
uncertainties in large sea salt concentrations and distributions. 
Consideration of combining LAWS and SCATT data may lead to 
special LAWS signal processing algorithms that will capitalize on 
SCATT ' s good near surface wind speeds and LAWS winds down to the 
top of the marine salt boundary layer. Use of an airborne 
downward scanning Doppler lidar will contribute significantly to 
our ability to interpret winds in this region. 

The potential of a SCATT/LAWS approach to winds over the 
ocean will be assessed by the proposer and R. Brown of the LAWS 
team. Scatterometer data from the 99 days of SEASAT operations 



in 1978 will be used with simulated LAWS winds over a limited 
study area. The SEASAT data will be obtained from the NOAA 
archives and/or researchers who can provide processed data sets. 

4.8 Post-launch Tasks 

The three post-launch tasks identified as objectives in 
Section 2.2 are: 

1) evaluation of the LAWS wind computation algorithm 
using ground-based facilities and numerical models; 

2) providing user data and services through EOSDIS; and 

3) using LAWS and other remotely sensed winds to study 
upper-tropospheric circulations as they relate to 
storm dynamics . 

The methodologies and resource requirements for post-launch 
evaluation of LAWS will need to be defined during the Definition 
Phase. It is expected that both ground-based facilities (e.g., 
surface networks, microwave sounders, rawinsondes, lidars, etc.) 
and numerical models (e.g., general circulation and regional 
scale models) will be employed. This proposal covers the 
participation in all phases of this evaluation but does not cover 
the costs of the ground-based facilities. 

A primary responsibility of the PI will be in providing 
users of the LAWS data with information on data quality, updates 
on algorithm modifications, and other obligations outlined in 
Part I of the EOS AO. This effort is not part of this proposal 
but is included in the Team Leader proposed for a team facility. 

The study of upper tropospheric circulations will be 
dependent upon the successful development of a LAWS wind 
computation algorithm that will resolve circulations with scales 
on the order of 100-500 km. 

Assuming that such capability will be available, LAWS data 
will be used to develop relationships between the magnitude of 
upper tropospheric divergence and other detectable attributes of 
the storm systems such as anvil growth rate, (GOES) , cloud top 
vertical velocity (GOES + LAWS), precipitation stage (GOES, AMSR, 
AMSU, TRMM) , and subcloud layer circulations (NEXRAD) . These data 
sets will be combined in case studies which may include Mesoscale 
Convection Complexes (MCC) , tropical cyclones, and extratropical 
cyclones . 


III. DATA PLAN 

1.0 General Overview for LAWS 

The Level 0 data from LAWS is a digitized time series of the 
line-of-sight signal intensity from the heteodyned detector. 



This time series must then be processed (Level 1) to produce an 
estimate of the LOS component of the wind. It is anticipated 
that the down-linked data will be the Level 0 digitized signal 
and that all further processing will be ground based. _ The 
exception to this may be some on-board signal processing 
necessary for managing the lidar shot budget - i.e., shot 
suppression and timing. 

After the LOS components (Level 1) of the wind speed are 
determined, they can either be used directly to regress against 
modeled wind fields or be combined through algorithms to produce 
model independent estimates (Level 2) of the horizontal wind 
field. This proposal is directed primarily at the task of such 
wind computation algorithm development and evaluation. 

2.0 Data Set Products, Validation and Updating 

In the following subsections of this data plan, three data 
products are considered: 

i) LOS wind components with their associated shot 

geometries, global locations and signal qualities 
(Level 1) ; 

ii) Horizontal wind components (u and v) for TBD areas 
of averaging (Level 2) ; and 

iii) LAWS winds and GOES cloud winds (or scatterometer 
winds) combined to produce hybrid wind data sets 
(Level 3 ) . 

2.1 Input Data Requirements 

During the execution and pre-launch phases the LAWS facility 
team will need access to GOES imagery for input to CLOS and cloud 
tracking studies, GLOBE backscatter data for use in ongoing 
Observing System Simulation Experiments, and any current 
satellite data sets (e.g., AVHRR, TOVS , GOES/VAS) that may 
provide global and/or mesoscale distribution of thin cirrus 
clouds. The NOAA series of polar orbiters are expected to 
provide the most appropriate set of CLOS and cirrus data since 
those instruments have nearly the same perspective in time and 
space as will the LAWS (assuming LAWS is launched on a polar 
platform) . 

It is proposed that the PI will access the data sets 
mentioned above through a PC version of the McIDAS system. Such 
a version is currently operational and would be used with either 
SPAN or SURANET. It is also possible that some of the Pathfinder 
data sets could be used for these pre-launch studies. 

In the pre-launch portion of the E/O phase there will be a 
need for some ground-based or other form of "truth" for 
demonstrations of lidar system performance and algorithm 



validity. Although lidar comparisons have already been done 
using tower anemometers, rawinsondes, radars and aircraft, it 
will be desirable to have the facility to evaluate various 
versions of LAWS as it goes through its design and pre-launch 
testing. The form of this facility has been addressed by the 
facility team during the definition phase. Presently, it is 
anticipated that an airborne Doppler lidar system will be 
available in the 1993-94 time frame. 

After LAWS is launched, ground-truthing will be carried out 
using the facilities developed for LAWS pre— launch testing as 
well as all other wind data available from conventional 
observation systems such as rawinsondes, surface networks and 
sounders (microwave, lidar, etc.). 

2.2 Algorithms 

A primary activity by the PI during the execution phase will 
be the development of algorithms for scheduling lidar samples 
(shot management) , processing the digitized LOS Doppler 
information and combining the LOS's to obtain estimates of the 
horizontal components of the wind. Current and new algorithms 
will be evaluated using computer models of the LAWS system and 
atmospheric models such as GCMs and regional scale models. 

Pre-launch algorithm validation will be accomplished 
primarily through computer simulation and ground-based lidar 
scanning simulation. Priority would be given to those algorithms 
necessary to programming the LAWS scanning and pulse control 
systems. The level of control, addressed during the definition 
phase, may range from fixed to real-time controllable based upon 
on-board data processing or up-linked commands. 

Computer requirements will be significant for the OSSE's 
owing to their use of GCM and global data sets. Currently the 
OSSE's are being run on the GSFC CRAY YMP. NASA/MSFC's CRAY XMP 
would also be adequate for any future algorithm evaluation. 

Algorithm evaluation will be a primary task of the facility 
team after LAWS is launched. Depending upon what the team 
decides will be the Level 2 product, it is likely that there will 
be several processing options to meet user's needs. For example, 
there may be a first order set of soundings that would provide 
the highest spatial resolution for research purposes and a second 
order set of soundings involving lower FARs for operational 
needs . 

2 . 3 Output Products 

All LAWS algorithms and data outputs will conform to the 
standardized scientific formats to be specified by IWG and be 
submitted to EOSDIS as required. 



2.4 Distribution Plan 

While the distribution of LAWS data would be through EOSDIS 
and its DAACs , the data processing, validation and user servicing 
may be done under contract. Distribution would be done both in 
real-time to the operational users and also from the data 
archives for other users. 

2.5 Definitions of User Requirements 

During the definition phase, the LAWS facility solicited 
potential user requirements regarding wind (and backscatter) data 
averaging, accuracy, and format. It is expected that the LAWS 
team will continue to interact with critical user groups and make 
changes to the data definition and distribution formats. 

It is further expected that there will be significant 
interaction between the LAWS team and other teams with 
instruments that measure quantities that are transported by the 
winds (e.g., water vapor, ozone, C0 2 , etc.). This interaction 
should be initiated as soon as possible since sampling overlays 
from different instruments presents a major input to both 
instrument hardware design and operations. 

2.6 EOSDIS Support 

During the Executive Phase, the algorithm development will 
require significant EOSDIS support. That support must be in the 
form of training, data manipulation tools, programming standards, 
simulation environments and the necessary hardware and 
communication networks. 


IV . MANAGEMENT PLAN 

1.0 Team Member Responsibilities 

G.D. Emmitt proposes to have a primary responsibility on the 
LAWS facility team for the Levels 1 and 2 (especially Level 2) 
processing algorithm development, evaluation and implementation. 
Contributions to the team would build upon his experience already 
gained from membership on the LAWS Instrument Panel, EOSDIS 
Science Advisory Panel and research on lidar shot management and 
wind computation algorithms over the last 8 years. Furthermore, 
the PI would direct and participate in the proposed scientific 
study of upper tropospheric cloud related circulations and would 
publish the results in refereed journals. 

2.0 SWA General Management Structure 

Within SWA, the management structure to support the proposed 
work is illustrated in Fig. 6. Each position's responsibilities 


are outlined as follows: 


PROJECT DIRECTOR - Overall responsibility for the 

execution of the proposed work including 
attending facility team meetings 
throughout the year. 

ASSISTANT DIRECTOR - Day-to-day management of the project 

components in a manner that will assure 
the meeting of the work schedules. This 
is a full time position with the respon- 
sible person also serving as Data 
Quality Control Manager. 

ATMOSPHERIC MODELING - Responsible for all in-house model- 
ing - e.g., lidar system, radiative 
transfer, turbulence, mesoscale, etc. 

This person is also responsible for 
interfacing with LAWS modeling efforts 
being conducted elsewhere (e.g., OSSEs 
at GSFC or MSFC) . 

ALGORITHM DEVELOPMENT /EVALUATION - Responsible for the _ 

development and evaluation of algorithms 
for shot management, LOS signal process- 
ing and horizontal wind computation. 
Evaluation tasks include both modeled 
performance and ground— truthing . 

ENGINEER SUPPORT - This category of tasks covers all support 

obtained via consultants. It is expected 
that several consultants will be used in 
the area of optimizing data processing 
algorithm. 

3.0 The Science Management Plan 

The management of the science will follow the same lines of 
responsibility as is shown for the general management structure 
with the exception of engineering support. 

4.0 The Milestone Matrix, Execution Phase 

The proposed Execution Phase effort will be managed in a 
manner so as to adhere to the milestone matrix presented in the 
EOS AO documents and reproduced below with some additions. 












IV. 


COMPUTER FACILITIES PLAN 


1.0 General Computing Requirements 

To define our computational requirements we break our 
execution phase activities into four types: 

1) global scale OSSEs; 

2) regional scale modeling and data assimilation; 

3) Level 1 and 2 algorithm development for use in 
proposed post— launch studies — includes interfacing 
with EOSDIS ; 

4) Processing and manipulating large data files 
(satellite images, radar scans, NOAA/ECMWF analyses, 
etc.) in support of 2 and 3 above. 

Given our current access to both GSFC's IBM and CDC amd CRAY 
computer and MSFC's Cray XMP, we are assuming that all global 
simulations can be performed on those systems. The research 
interests of Bob Atlas, Tim Miller and T. Krishnamurti make the 
use of these common facilities even more imperative. The 
remaining three types of computing activities should be conducted 
using the team members on-site SCF . 

2 . 0 Hardware Requirements 

The use of regional scale models such as LAMPS, MESO, or 
, is going to be limited to non-real time simulations in 
support of algorithm development and LAWS based research. A 
workstation would be adequate for this activity. 

Development of Level 1 and 2 algorithm can be accomplished 
with desktop PC-28 6s. However, to assure compatibility and 
operability of those algorithms in the EOSDIS environment, the 
operating system should be unix or posax. Again, a workstation 
is more than adequate for this activity. 

Given that LAWS will be providing one of several wind 
measurements, we will be spending much effort in combining the 
LAWS data with radar data, cloud tracked winds scatterometer 
winds, conventional winds, SWIRLS, etc. This will be the most 
demanding computational activity. This activity is the essence 
of the interdisciplinary research encouraged by the EOS program 
and around which the EOSDIS is being designed. 

Prior to the TM receiving the hardware, and software 
required for EOSDIS interfacing, much of the type 4 activities 
will be carried out using the McIDAS software. For this we will 
need a PC-486 with the OS/2 operational system plus peripherals 
listed in the cost proposal. However, when the EOSDIS system is 
ready for interfacing (1994?) , we intend to slowly transfer many 



of these data display and analyses activities over to an EOSDIS 
workstation environment. 

In summary, team member's proposed EOS program and 
scientific activities can be supported with: 

1) access to GSFC and MSFC's mainframe computers; 

2) a PC-4 8 6 /OS/ 2 computer and peripherals; and 

3) workstations equipped for optimal interfacing with 
EOSDIS. 

2.1 Peripherals 

In addition to the computational requirements above, we will 
need the following related hardware capabilities: 

1) 10 Gbyte storage medium; 

2) 6250 magnetic tape drive; 

3) upgrade on our Tektronix color printer; 

4) 9600 baud modem; and 

5) several utility laser printers. 

3.0 Software 

At this point in time it is very difficult to be specific 
on our CAS or EOSDIS provided software needs. In addition to the 
generaly available software packages such as windows, graphics, 
etc., the proposed research demands highly interactive image and 
gridded data processing, display and recording. It is 
anticipated that initially this demand will be met by NASA 
provided McIDAS capability and eventually be provided by EOSDIS. 

4 . 0 Communications 

Currently we are linked to GSFC and MSFC via 2400 baud dial- 
up modems. This is a major limitation to our abilities to 
develop optimal data product algorithm for use in global OSSEs. 
Also, the transmission of images and large gridded data sets over 
the EOSDIS network will require at least 128M baud capability 
within the next 3-5 years. Until that capability is provided, we 
can operate with a 9600 baud dial-up without any dedicated 
communication line. 
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